Skip to content

feat(decisions): surface L1 supersession lineage in the archive#1416

Merged
jaylfc merged 2 commits into
devfrom
feat/decisions-history-view
Jun 23, 2026
Merged

feat(decisions): surface L1 supersession lineage in the archive#1416
jaylfc merged 2 commits into
devfrom
feat/decisions-history-view

Conversation

@jaylfc

@jaylfc jaylfc commented Jun 23, 2026

Copy link
Copy Markdown
Owner

What

The Decisions L1 supersede backend (#1339) records a parent_decision_id chain and serves it at GET /api/decisions/{id}/history, but the app only rendered a flat Superseded label with no way to see the lineage. This adds an expandable history trail.

Behaviour

  • Answered cards that have a parent (a revision) get a View history toggle.
  • On first expand it lazily fetches /api/decisions/{id}/history (one request per card, only when opened) and renders the chain oldest first: each step's question, chosen answer (or superseded), and relative time.
  • Originals with no parent show no affordance.
  • Read-only; reuses the shell design tokens already in the file.

Tests

  • DecisionsApp.test.tsx: 2 new cases (no affordance for a parentless decision; lazy-load + render the lineage for a revision) plus the existing 5. All 7 green; tsc -b clean.

Verification note

Behaviourally verified via vitest (jsdom). Visual check against the running app is deferred to a live session, since the trail needs the live backend to populate, consistent with the canvas read-only slices.

Completes Decisions MVP item 6 (L1 supersede) on the frontend; the backend already shipped.

The supersede backend (#1339) records a parent_decision_id chain and serves it
at GET /api/decisions/{id}/history, but the app only showed a flat 'Superseded'
label with no way to see what replaced what. Add an expandable history trail on
answered cards that have a parent (a revision): it lazily fetches the chain on
first expand (oldest first) and renders each step's question + chosen answer +
when. Originals with no parent show no affordance. Read-only, reuses the shell
tokens already in the file; vitest covers the expand/fetch/render path and the
no-parent case. Visual check against the live app deferred to a live session
(same as the canvas read-only slices).
@qodo-code-review

Copy link
Copy Markdown

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@coderabbitai

coderabbitai Bot commented Jun 23, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@jaylfc, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 2 minutes and 26 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: aa19f716-6ab6-45f9-9084-24263764c29d

📥 Commits

Reviewing files that changed from the base of the PR and between d9249bc and 9b37a79.

📒 Files selected for processing (2)
  • desktop/src/apps/DecisionsApp.test.tsx
  • desktop/src/apps/DecisionsApp.tsx
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/decisions-history-view

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

Comment thread desktop/src/apps/DecisionsApp.tsx Outdated
Comment on lines +337 to +351
async function toggle() {
if (open) {
setOpen(false);
return;
}
setOpen(true);
if (chain || loading) return;
setLoading(true);
setError(null);
try {
const res = await fetch(`/api/decisions/${decisionId}/history`);
if (!res.ok) throw new Error("Could not load history.");
setChain(asDecisionList(await res.json()));
} catch (e) {
setError(e instanceof Error ? e.message : "Could not load history.");

@gitar-bot gitar-bot Bot Jun 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Bug: HistoryTrail can setState after unmount during fetch

toggle() issues an async fetch and then calls setLoading, setChain, and setError in the try/catch/finally. If the card unmounts while the request is in flight (e.g. the answered list refreshes via the parent's load() polling, or the user switches tabs), these setState calls run on an unmounted component. There is no AbortController and no mounted-ref guard, so the in-flight request is neither cancelled nor ignored. Impact is limited to a wasted request and a possible React state-update-on-unmounted-component warning rather than a crash, hence minor. Suggested fix: track mounted state with a ref (or use an AbortController stored per-toggle) and bail out before setting state.

Guard state updates with a mounted ref:

const mounted = useRef(true);
useEffect(() => () => { mounted.current = false; }, []);
// ...inside toggle(), wrap each post-await setState:
if (!mounted.current) return;
setChain(asDecisionList(await res.json()));

Was this helpful? React with 👍 / 👎

@gitar-bot

gitar-bot Bot commented Jun 23, 2026

Copy link
Copy Markdown

Note

Your trial team has used its Gitar budget, so automatic reviews are paused. Upgrade now to unlock full capacity. Comment "Gitar review" to trigger a review manually.
Learn more about usage limits

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Implements an expandable lineage trail for superseded decisions, enabling users to view revision history. Ensure the HistoryTrail component handles state updates after unmount to prevent potential race conditions during the asynchronous fetch.

💡 Bug: HistoryTrail can setState after unmount during fetch

📄 desktop/src/apps/DecisionsApp.tsx:337-351

toggle() issues an async fetch and then calls setLoading, setChain, and setError in the try/catch/finally. If the card unmounts while the request is in flight (e.g. the answered list refreshes via the parent's load() polling, or the user switches tabs), these setState calls run on an unmounted component. There is no AbortController and no mounted-ref guard, so the in-flight request is neither cancelled nor ignored. Impact is limited to a wasted request and a possible React state-update-on-unmounted-component warning rather than a crash, hence minor. Suggested fix: track mounted state with a ref (or use an AbortController stored per-toggle) and bail out before setting state.

Guard state updates with a mounted ref
const mounted = useRef(true);
useEffect(() => () => { mounted.current = false; }, []);
// ...inside toggle(), wrap each post-await setState:
if (!mounted.current) return;
setChain(asDecisionList(await res.json()));
🤖 Prompt for agents
Code Review: Implements an expandable lineage trail for superseded decisions, enabling users to view revision history. Ensure the `HistoryTrail` component handles state updates after unmount to prevent potential race conditions during the asynchronous fetch.

1. 💡 Bug: HistoryTrail can setState after unmount during fetch
   Files: desktop/src/apps/DecisionsApp.tsx:337-351

   `toggle()` issues an async `fetch` and then calls `setLoading`, `setChain`, and `setError` in the `try/catch/finally`. If the card unmounts while the request is in flight (e.g. the answered list refreshes via the parent's `load()` polling, or the user switches tabs), these setState calls run on an unmounted component. There is no `AbortController` and no mounted-ref guard, so the in-flight request is neither cancelled nor ignored. Impact is limited to a wasted request and a possible React state-update-on-unmounted-component warning rather than a crash, hence minor. Suggested fix: track mounted state with a ref (or use an AbortController stored per-toggle) and bail out before setting state.

   Fix (Guard state updates with a mounted ref):
   const mounted = useRef(true);
   useEffect(() => () => { mounted.current = false; }, []);
   // ...inside toggle(), wrap each post-await setState:
   if (!mounted.current) return;
   setChain(asDecisionList(await res.json()));

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact
gitar display:verbose         

Important

Your trial ends in 3 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

Was this helpful? React with 👍 / 👎 | Gitar

if (chain || loading) return;
setLoading(true);
setError(null);
try {

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SUGGESTION: No abort handling on the in-flight history fetch. If the user collapses the panel, switches tabs, or the card unmounts (e.g. silent refresh re-renders the archive after an answer in the same view) before the request resolves, setLoading/setChain/setError will still run on an unmounted component. Consider an AbortController per fetch and check controller.signal.aborted (or a mounted ref) before calling the setters in the finally block.


Reply with @kilocode-bot fix it to have Kilo Code address this issue.

Comment thread desktop/src/apps/DecisionsApp.test.tsx Outdated
fireEvent.click(historyBtn);
await flush();

// The chain is fetched lazily on expand and rendered oldest first.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WARNING: The PR description and the inline comment both explicitly claim the chain is "rendered oldest first", but this test never asserts ordering. The mock returns [original, revision] in the right order and the assertion is only expect(screen.getByText(/superseded/i)).toBeTruthy(), which would pass even if the component rendered newest-first or in reverse. Add an ordering assertion (e.g. read the <li> nodes and verify the original's question appears before the revision's) so this behaviour is actually pinned by the test suite.


Reply with @kilocode-bot fix it to have Kilo Code address this issue.

@kilo-code-bot

kilo-code-bot Bot commented Jun 23, 2026

Copy link
Copy Markdown

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Both issues from the previous review are resolved in commit 9b37a797:

  • SUGGESTION (DecisionsApp.tsx): HistoryTrail now tracks liveness with aliveRef (cleared in the unmount cleanup) and gates every post-await setState (setChain, setError, setLoading) on it, preventing updates after unmount.
  • WARNING (DecisionsApp.test.tsx): The "loads and renders the supersession lineage" test now actually asserts oldest-first ordering via data-testid="decision-history" and within(...).getAllByRole("listitem"), checking that the original precedes the revision.

No new issues found in the incremental changes.

Files Reviewed (2 files)
  • desktop/src/apps/DecisionsApp.tsx
  • desktop/src/apps/DecisionsApp.test.tsx
Previous Review Summary (commit b3bbc78)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit b3bbc78)

Status: 2 Issues Found | Recommendation: Address before merge

Overview

Severity Count
CRITICAL 0
WARNING 1
SUGGESTION 1
Issue Details (click to expand)

CRITICAL

None

WARNING

File Line Issue
desktop/src/apps/DecisionsApp.test.tsx 222 The new test does not actually assert "oldest first" ordering despite the PR description and the inline comment claiming it. The only history assertion is getByText(/superseded/i), which would pass regardless of render order.

SUGGESTION

File Line Issue
desktop/src/apps/DecisionsApp.tsx 346 HistoryTrail does not abort its fetch on unmount; setters will run on an unmounted component if the card disappears (e.g. tab switch, silent refresh) before the request resolves.
Files Reviewed (2 files)
  • desktop/src/apps/DecisionsApp.tsx - 1 issue
  • desktop/src/apps/DecisionsApp.test.tsx - 1 issue

Fix these issues in Kilo Cloud


Reviewed by minimax-m3 · Input: 39.2K · Output: 1.3K · Cached: 55.5K

Fold #1416 review: an archive card can unmount mid-fetch (tab switch or list
refresh) while /history is in flight, so the post-await setState would warn and
leak. Track liveness with a ref cleared on unmount and gate every post-await
setState on it (gitar Bug; kilo concurs). Also assert the oldest-first ordering
the description claims, via a testid on the history list (kilo).
@jaylfc jaylfc enabled auto-merge (squash) June 23, 2026 18:23
@jaylfc jaylfc merged commit 1e28bda into dev Jun 23, 2026
8 checks passed
@github-project-automation github-project-automation Bot moved this from Todo to Done in TinyAgentOS Roadmap Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant